Mobile computing devices such as smartphones and tablet computers are becoming more widely used every day. Android is an open-source, Linux based operating system for such mobile devices that is gaining an increasingly prevalent market share. A large community of developers write applications (“apps”) that run on Android devices. Many of these apps are available either for purchase or for free through the online Android Market, which is run by Google. Android apps can also be downloaded from other online stores and additional third-party sites. With the open nature of the Android environment, anyone can create and distribute Android apps.
Because of its openness, the Android platform is vulnerable to an attack called trojanization. To implement this attack, a malicious party starts with a legitimate app, downloaded from an online store or other source. The attacker strips the app's digital signature, adds additional (malicious) code to the app, resigns the app with an anonymous digital certificate, and redistributes the now malicious app to unsuspecting users through one of the existing channels. In effect, the attacker is taking advantage of the openness of the Android development and distribution environment to hide malicious code in an existing, legitimate app. Users seeking to download and run the legitimate app are tricked into downloading the trojanized version. When the trojanized app runs on the user's Android device, the new code the attacker added can execute malicious functionality, such as stealing contact information, logging data input, sending fraudulent communications, etc.
Mobile security products exist for Android which analyze apps, and warn users of potentially malicious behavior. An Android app is distributed in the form of an APK (Android Application Package) file. These security products examine APK files and attempt to identify potentially malicious code. Such products typically examine the permissions that an app (or other type of application) requests, and then warn the user concerning the ways in which the requested permissions can be misused. For example, an app with permission to send text messages could fraudulently send numerous premium rate service messages, resulting in a large bill for the user. An app with GPS access and network communication privileges could track the user's location, and transmit this information to a malicious party. Likewise, apps with permissions allowing them to send emails, make phone calls, record audio and/or video, etc., can use these access privileges for malicious purposes.
The use of such permissions is legitimately required by many benign apps, such as navigation apps, appointment dialers, camera apps, etc. The fact that an app requests a given permission (e.g., use of the phone on a mobile computing device) is not a cause for concern in and of itself. Certain types of apps, for example an appointment dialer, must use the phone to execute their primary functionality. On the other hand, other types of apps, for example a wallpaper app, would not be expected to use the phone. Thus, warning a user that an app requests permissions that can be used for malicious purposes is of limited helpfulness. Many benign apps have legitimate needs for these permissions. When presented with a warning that an app seeks various permissions that could enable malicious behavior, an average user does not know if the app does or does not have a legitimate reason for requesting the permissions. Note that the potential for attacks and the security analysis described herein are not limited to Android apps, but can also occur in the context of applications for other mobile or desktop computing environments.
Some security products for mobile apps (as well as other types of applications) also analyze actions performed by applications, for example by running an application in a confined environment and monitoring what actions the application performs. As with the identification of permissions requested by apps discussed above, these products identify actions that could be used maliciously. For example, such analysis can identify that an application sends emails or text messages, records video or reads privacy sensitive information, such as the user's contacts or the device's International Mobile Equipment Identity (IMEI). As with requesting permissions, these actions have legitimate as well as malicious uses. For example, an application that accesses the user's contacts and sends email messages could send the user's private contact data to a malicious party. On the other hand, it would be legitimate (and necessary) for an email client to access the user's contacts and send emails.
Simply informing the user that a given application requests permissions or performs actions that can potentially be used maliciously is not very useful to an average user. Because these permissions and actions have legitimate uses as well as the potential for malicious misuse, the user is not likely to know how to respond to a warning that an app requests certain privileges or performs certain actions. By heading all such warnings, the user will avoid benign apps that use the requested permissions and perform the detected actions for legitimate purposes. On the other hand, if the user ignores all such warnings, then the user receives no protection from the security product against downloading malware.
It would be desirable to address these issues.